How EMM Can Help You with GDPR Compliance
Webinar transcript - View the full webinar
Ojas Rege: This is a exceptionally important topic as we kick off 2018, GDPR and how you actually drive compliance. Today we're going to be diving in deep into what the elements of GDPR compliance are for Mobile. MobileIron is a security company. We're focused on this intersection of mobile and cloud.
Whenever you have these computing technologies change, there's a real implication for the way that you manage regulations and the controls that you have to put in place to be able to make sure that you can comply, especially with these new regulations that many times have not been tested in any organizations.
This discussion today is not legal advice. We're going to be discussing best practices. I'll be sharing with you the different elements of what we see our customers doing. Every organization, of course, should consult with its own legal counsel to define an appropriate compliance strategy for their team.
The GDPR, General Data Protection Regulation is one of the fundamental regulations that's going in place this year. Of course, it's driven in Europe, but as we'll talk about, it has massive implications, not just for companies based in Europe, but any company. In essence, any multinational that's based in the US or any other country in the world that has employees or customers that are based in Europe.
Now, there's not a lot of days left to drive to compliance. We have 121 days and actually five hours and approximately 15 minutes before GDPR officially gets in place and becomes enforced on May 25th, 2018.
For those who haven't, the EUGDPR sites, .org site that you see at the bottom of the right hand side of the screen here is a great reference from the European Commission. The impact of GDPR compliance is huge.
This is a quote that was in TechCrunch just a couple of days ago about Facebook. Facebook has told TechCrunch that they've assembled the largest cross functional team in the history of its family companies to support GDPR compliance, because, of course, it affects every element of an organization and the way that organization structures its data.
Today, we're not going to take on a problem quite that big, because we're going to focus on endpoint security and GDPR in the context of endpoint security. Why is it essential? Why does endpoint security matter so much for GDPR compliance?
If I have a phone and let's say, I have Workday, which is a very popular cloud‑based service. When I download an application, the Workday application to my phone, I now have information from Workday on my device itself.
Workday, of course, has a lot of HR information that...By definition, there's a lot of personal information about my employees in this case that's now on my device. If I forget that device in a taxi, and that taxi drives away, I now have lost control and visibility over a very important set of personal information that absolutely needs to be protected in the GDPR context.
Given that so much business information ends up on a device, a mobile device, and so much of that information will include what GDPR thinks of as personal information, endpoint security becomes essential for compliance.
What's interesting about GDPR is what people are thinking about it right now, but what they're mainly focused on, which is actually the main focus of GDPR, is how organizations are using information from the public consumer information. Consumer protections become incredibly important.
This is the catalyst for GDPR in the European Commission. We're looking at something a little bit different here. What we're looking at in this presentation is your internal systems. As you deploy services to your mobile employees, how do you make sure that that deployment is GDPR compliant?
When you think about personal data, there's two elements to it. One is the personal data of your employees and you don't want to have access to any personal data from your employees that you shouldn't have. But the other is that you already as an organization have a tremendous amount of personal data in your organization, about your employees and your customers.
For many large organizations, a large set of those employees and customers are based in Europe, so GDPR applies.
The best assumption, the common baseline assumption that I think is the right one to make is that assume that every single business service that you are making available to your employees has some level of personal data in it, even email addresses, contact information and so forth is considered personal data in a GDPR context.
What that means is that every service that I've deployed within my organization will have something that constitutes personal information in a GDPR context. I now have to protect that information when it's on my mobile devices.
Let's talk about what the rule is of different technologies. GDPR is really codifying some reasonable data security and privacy practices that are becoming more and more relevant across the globe.
Yes, we have a catalyst, which is GDPR compliance that happens in 2018, but the philosophy and the policies and the standards underneath it are shared with many of the other regulations that are taking place in United States and other countries.
The clear trend that we see in the law towards codifying and enforcing what I thought of as reasonable data security standards. IDC in their Western European mobility practice, last year, as company started to start thinking about GDPR specifically said that EMM, Enterprise Mobility Management, the technology becomes crucial for GDPR compliance.
The nice thing about GDPR from a mobile perspective is, yes, there's work that organizations have to do, but it's not a technical problem. The technologies exist to drive compliance. What needs to be put in place is the design of the program, and then the process to reach that compliance state. That's what we'll be talking about here today.
Let me dive, not in a lot of detail, because there's quite a bit of complexity in the GDPR principles. Let me at least dive at a high level into some of the elements of GDPR. Of course, understanding these elements is essential to understand how the different controls you put in place are going to be irrelevant for GDPR.
The first, lawful, fair and transparent processing. This means any personal information that you have, you need to have a reason for that. [laughs] There needs to be a reason that you have that and that you're processing the personal data.
For example, you need information potentially, for your employees in order to be able to give them health insurance, in order to be able to pay them. You need access to their bank account. But you don't need access to all their bank accounts, you only need access, you only need that information so payroll can automatically deposit funds in their savings or checking account when it's payable time.
That's why purpose limitation. The second one, the one that's one is important, which is you will inevitably have personal information about your employees and customers, but there needs to be a clear and explicit reason for it.
It can only be processed. The data can only be processed for the purpose for which it was collected. Need to consent to that in the JUUL, be able to do that. You need to minimize the data that you have.
Again, you'll see these minimization themes all the time, which is inevitable that a company has personal data about its employees and customers, but you should only have the minimum amount of personal data not more than you need.
The data should be accurate, you should store it for certain periods of time, you should protect, of course, integrity and confidentiality. You should be able to be accountable, meaning demonstrate compliance with all these different principles.
Now everyone who's on the phone, your organizations have legal and compliance teams that are looking at GDPR, in much more detail and have their own interpretations of all of these.
At high levels, we bubble up from what the documents say, for GDPR and what the implication is, is it means that you shouldn't have more personal information about your employees or customers than you need. The information that you do have, you should only use for its intended purpose and you should protect it. Absolutely essential that that information not be lost.
It's 17 weeks left until GDPR enforcement starts in May 2018. This affect any organization anywhere in the world that has employees or customers in Europe, which is actually most of MobileIron's customers, and in obviously, the folks on the phone here today.
We have a white paper that we put together specifically around the steps that you can take to set a baseline for GDPR compliance. As a follow up to this webinar, we'll actually send you a link to that as well.
Let's talk about the details of what that process is. From a mobile perspective, the concept here is containment. Containment of business data is critical. Business data, when I refer to business data, I'm talking about all the data that your organization has, which includes, by definition, a lot of data about individual.
Personally, there will be no business data service in organization that doesn't have at least some personal data. Let's look at this at a very high level first and we'll dive into some of the elements of driving to compliance.
The first is you need to be able to provision a business work space to the device. Be able to provision the business applications and configurations to the device. Any of you on the phone who deployed mobility probably understand this process very well, and the separation of the business applications from the personal applications.
The second is that that separation needs to be distinct. It shouldn't be possible for the business applications to share data with the personal applications. I need to provide the business applications on the device. I need to separate the data on the device and actually in network.
If, for example, any of those applications are connecting back through VPN, to an On‑premise system, trust the business applications to connect to a VPN. If you have a device Web VPN, then you'll actually have personal traffic in your network as well.
Very important to separate the data on device and the network, and then prevent sharing between the business and the personal apps.
Finally, need to be able to delete just the business applications and configurations when the employee leaves the company, when the device falls out of compliance, when a whole variety of actions or events might happen, that mean that you no longer need to have business data on that particular device.
At the highest level, these are the four ‑‑ their principal concepts, provisioning the work space, separating the data, preventing sharing between business and consumer applications, and then deleting just the business applications and configurations and leaving the personal data alone. That separation you'll see again and again as you think about GDPR and the process to let it support it.
Let's dive into the details. How do I actually get in my organization to a GDPR baseline for my mobile deployment?
Step number one, every single device that you have, every mobile device needs to be under management. The reason that all those authorized devices needs to be under management, it's when you have a device under management, you can selectively wipe just the business data from the device and without damaging in any way shape or form the users' personal email apps or photos.
If you don't have a device under management, and that device gets lost, then the only action that you can take is a full device wipe through a technology like ActiveSync.
For those on the phone, who have devices in their organization, iPhones, iPads, Android devices, and so forth, that are only right now being managed through ActiveSync, that ends up becoming a GDPR issue because there is no way in that model to be able to wipe just the business data of the device.
You will end up the entire device which will of course damage personal data. The second step is to apply up to date configurations and specifically enforce encryption, password and other device security measures. This is mobile security 101. Anyone who has deployed any type of a structured security program has probably already done this, which is a good thing.
It's good not to have to redo everything for GDPR. The reason this step is so important is twofold. One, is we need to mitigate the risk of a lost device. Yes, devices do get lost. The ability to ensure that the device is encrypted, that there's password, there's other security mechanisms mitigate the risk of that data than being compromised.
The other reason is that encryption is the only technology that's actually actively mentioned within the GDPR. The other GDPR does not specifically talk about technology, it talks about what the requirements are.
Then of course, organizations have to identify the right technologies as IDC identified EMM is a core technology, but encryption is a specific element that is mentioned in GDPR and probably not a great surprise for anyone on this call, being able to ensure that any of the devices on which your business data resides are encrypted ends up becoming important.
Because if you do have a data breach, you need to be able to show within a GDPR context that you followed what are called state‑of‑the‑art mechanisms to be able to protect that data, which means that you utilize technology in the best possible way within reason to be able to provide the right security standards for that type of data.
The third. All business apps should be delivered as managed apps. What this means is that if you have business applications that you wish your employees to access on their mobile device...That could be Office 365 applications or Salesforce1 or in‑house applications you've built. There's a wide set of applications.
We see on average our customers have 10 or more applications for their employees on those devices. All those applications have to be managed. What that means is they need to be distributed through the enterprise app store to the device.
If they come directly from the Apple App Store or from Google Play, then you will have GDPR compliance issues because IT will not be able to delete that business application from the device if the device is lost or if the employee leaves the company.
The fourth one is once you have those applications on the device, the data sharing needs to be controlled between those applications and others. Specifically, business applications should not be able to share data with consumer applications on the device because your business applications have personal information in them as I mentioned earlier.
The moment that information leaves that business application on the device and goes to another personal application, you as IT lose all visibility and control over it. That's a clear issue in a GDPR context.
There's another side of this too, which is you want to make sure that you maintain visibility of your data, but you also want to make sure you don't have any visibility of data you shouldn't see, back to the minimization and purpose rules we talked about earlier. This is where the way you think about VPN becomes really important in GDPR context.
If you have cloud services, this may not matter. If you have on‑premise services on the back end, if your device is connecting through a device‑wide VPN to your network, then that means personal traffic, Facebook traffic, Twitter traffic, my browsing traffic, all of that traffic is going to your network as well, which is giving you as an organization inappropriate visibility into that personal traffic.
What this means is on the device, there need to be controls like open and control so you can only open information within applications that you as IT dictates as being business. Also, when applications connect to the back and the notion of per‑app VPN instead of device‑wide VPN.
Numbers one, two, three, and four that I've talked about here so far, these are the fundamentals of mobile security. This doesn't mean that all organizations have these in place.
If you have an EMM solution and you have put all your devices in management and you have applied the up‑to‑date configurations and you've made sure that all your business applications are distributed through an enterprise app store with the right controls, then you will have put in place the mechanism that you need here.
The containment pieces that I showed earlier containing the applications and making sure that disassociated and personal data doesn't leak, you will have managed that through one, two, three, and four.
Number five is a big hole in most organizations' security strategy, then GDPR makes that security gap that much more relevant. You have to be able to block unauthorized devices and apps from accessing cloud services.
If I have Office 365 or Workday or Salesforce on the backend and I have a iPhone, let's say, or an Android device onto which I download the appropriate application, I can now log into that back‑end service, and that data will be synchronized to my device.
The problem is that device is not managed, the application is not managed, and you as IT now cannot delete the information that's on the device. You cannot prevent that information from being shared with other applications. In essence, the moment that the information has left the back‑end cloud service, it's now outside your control.
That's a big issue. What's important here is to make sure that unauthorized devices and apps are not allowed to access services like Salesforce, Boss, or any of the other services that you might have.
It's not enough that it's a trusted user. It's also essential that the device and the application that that trusted user is using are under the control of IT and that you can actually control and delete the data when it's necessary. This is the single biggest security hole that we see in cloud deployments today, and it's very relevant for GDPR.
Number six is actually nothing to do with technology. Number six is about communication, because as we all know, if this security and privacy program is not effectively communicated to the user base, then employees are not going to adopt the security program the way that you want.
Finally, hopefully no one on the phone here will be in this situation, but the reality is there will be breaches. We see this all the time. GDPR has a strict notification periods for breaches, sometimes even 72 hours. This means that whatever mobile deployment you have, your inventory, for usage, for audit logs, needs to be in place to support quick response.
Otherwise, it will be difficult to identify, report, and respond if there is a breach. Steps one, two, three, four, five, six, seven, we believe, set a baseline that is a appropriate baseline for any organization to be at with their mobile GDPR compliance. Here's the problem, though.
Most mobile organizations haven't been proactive about GDPR compliance because most of big thorny issues around GDPR are not around mobile. They're around the way that all of the back‑end systems that our organization uses are structured and how that organization is leveraging and using customer data.
Many times, what's happening in organizations is the mobile team is waiting for the compliance organization or the legal organization to provide the appropriate checklist or questionnaire.
The problem is that that may not come until March, April, until very close to the endpoint of GDPR compliance, which is May of 2018. What we're recommending certainly to all our customers, but really anyone who has a mobile strategy, is be proactive.
These steps can be put in place right now and that will put the mobile portfolio of your organization in a really good stage for GDPR compliance.
Not to say that there won't be other things you might have to do later on down the line, but rather than leave it to the last minute given that this is a problem that can be resolved much more easily on mobile than it can be on many back‑end systems, the time is right obviously now with only [laughs] 17 weeks left to start putting these capabilities in place.
For those on the phone who are MobileIron customers, MobileIron is an EMM platform, so all of the one through seven can be accomplished through the core MobileIron service. But MobileIron Access, which is specifically our access control mechanism for blocking unauthorized devices or apps becomes really, really key.
A good thing to think about this, in summary, is that in order to be compliant with GDPR, all devices should be under management, all applications should be managed and should have a mechanism to ensure that unauthorized devices and apps are not able to access any of your cloud services.
For those who are customers and partners of MobileIron, you may also want information about how we as an organization ourselves are becoming GDPR compliant.
What I've talked about so far is how technologies like MobileIron can help our customers become GDPR compliant. But of course, right now, you have to evaluate also all of your technology vendors and ensure that they're doing the right things for their own GDPR compliance.
If you're a MobileIron customer or a partner, you can go to the community site, community.mobileiron.com. There's two documents there ‑‑ one about our internal GDPR compliance and one about privacy and security standards that you'll be able to search on GDPR and access.
One of the things that's very interesting right now I find is that when people think about GDPR, the service that pops to mind for them first is Office 365. It's absolutely essential to ensure that your Office 365 deployment, if you are going that direction, is GDPR compliant.
Remember, every company out there, certainly all of our customers, are not single cloud enterprises. They're multi‑cloud enterprises. The notions that we've gone through today, that I've described today need to be applied to all of the different cloud and premise‑based services that you have.
We as MobileIron just internally have dozens of cloud services that we use for different functions in the organization. I was at the Gartner Symposium not too long ago and the lead analyst for cloud security said that in his estimate, the average large enterprise has, at this point, hundreds of cloud services that they deploy.
All of those services will need to be evaluated for GDPR compliance. From a mobile endpoint perspective, any of those services which are actually being accessed from a mobile device end up falling into the map that I described earlier, the steps one through seven of how to drive GDPR compliance and make sure that the data on the endpoint is secure.
With that, I'm going to end off and just, again, remind everyone that we'll be sending you a copy of the white paper that goes through in much more detail those seven steps to be able to help you achieve GDPR compliance.
Mandy, let me turn it over to you. I'll answer any questions there might be there.
Mandy: Thank you, Ojas. Thank you for that presentation. Yeah, we do have a couple of questions that came in. First one would be what happen with unmanaged devices?
Ojas: Unmanaged devices are a big issue in GDPR. For those who are unfamiliar with the notion of management, what that means is that...what management means is that if you have an iOS, Android, Windows or Mac device, Windows 10, or Mac device, those devices are enrolled within an enterprise mobility management system like MobileIron.
When they're enrolled in that system, that system now is the trusted source of security policies for that device. That system can provision services to that device more importantly, from a GDPR context, that system can delete information off the device.
If you have an unmanaged device with let's say, a Salesforce1 application on it, you've got to beat GDPR issue, because if that device is lost, there's no way for you to delete the information on the device, and there's no way for you to prevent that information from Salesforce1 from making it into other applications on that device itself.
Which means that you've got a big vector of data loss for any personal information, personally identifiable information that might exists within your Salesforce deployment. Of course, for anyone who's used Salesforce, you know that there's a tremendous amount of personal information Salesforce, because you have all the contact information for your customers, and, frankly, your employees as well.
In the GDPR context, you should never have business information on an unmanaged device.
Mandy: Thank you. If you do have a question, definitely put it into the Q&A panel on the WebEx. The next question, Ojas, is how can WhatsApp with MobileIron become GDPR compliant?
Ojas: I think that WhatsApp that was the question, is that correct?
Mandy: Yes. How can it become GDPR compliant?
Ojas: WhatsApp, of course, is one of the most popular applications in the world for messaging. The company's wrestles, they struggle with what the role of WhatsApp should be within a corporate context.
From a MobileIron perspective, from a GDPR perspective endpoint side, you would distribute the WhatsApp app through MobileIron as an enterprise application. Meaning that you would publish it in the MobileIron enterprise app store and then that application would then be distributed to the device.
What that will let you do is if the user for example, left the organization assuming that they're using WhatsApp for Business, you could then delete the application on device. What that won't do is do anything on the back end service for WhatsApp.
There's two questions here, which is through MobileIron, you can absolutely protect WhatsApp on the device so there's no device‑side GDPR issues.
There's still an open question that you as an organization would have which is, "Well, what about the server side of WhatsApp, and does that meet the standards that you have for server‑side security within a GDPR or just a broader regulatory context?"
Mandy: The next question is does GDPR comply with DEP program?
Ojas: Could you repeat that again?
Mandy: Does GDPR comply with DEP program?
Ojas: EP? I don't know that the individual is referring to there, so I'll follow up with them offline just to make sure I know what they mean by EP.
Mandy: OK. The DEP program.
Ojas: Oh, DEP.
Mandy: Yeah, sorry. The Device Enrollment Program.
Ojas: No problem at all. DEP and GDPR are adjacent, not necessarily related, [laughs] but DEP would fit in very well within a GDPR mechanism. For those who are not familiar, DEP is the Device Enrollment Program which is Apple's way to do out‑of‑the‑box enrollment for devices.
In general, the devices that you're going to deploy through DEP are going to be relatively secure. One of the reasons that you're doing DEP is because you want to put a fair number of security controls on the device.
DEP and GDPR sit side by side. DEP is primarily going to help you ensure that every device arrives out of the box with the right compliance model already implemented. It'll probably save you time and energy and be helpful in terms of showing that you have a process that is easily replicable, and can scale across the GDPR deployment that you have.
You'll find it helpful. However, the real key to GDPR is not so much that you have DEP, but it's rather the policies that you're setting. As long as you've got the right policy set for those out‑of‑the‑box devices, then of course DEP will make it easier to make the policies more consistent across your fleet.
Mandy: Next question. Can iOS split tunneling still be used instead of Per‑App VPN?
Ojas: This really comes down to how you're structuring the communications from the device itself. The way that I would think about this is there's a security piece and there's a privacy piece, and you may have different mechanisms to think about those.
From a privacy perspective what's key is that I believe, and of course this is something you should check with your attorneys, is that you don't want information from personal applications on the device going through your corporate network.
Maybe they're going through a guest WiFi network. That's OK, but you certainly don't want them in general going through a corporate network. You certainly don't want to be inspecting that personal traffic.
You may be in certain regulated environments where you need to be inspecting everything, but then that needs to be clear to the user, but for 80, 90 percent of organizations, you would not want to be inspecting the Facebook traffic of your employee.
The way I would think about this from a technology perspective is to make sure that you're never in a situation where the personal data that's on the device is going through corporate networks.
If it is that you're aware of that, and that you put in place the appropriate mechanisms to be able to protect that privacy. In general, what we see customers doing when they're connecting to On‑premise services is using Per‑App VPN, which leverages the internal tunneling mechanisms that iOS has.
Remember Per‑App VPN is not just an iOS thing, it also works on Android, it also works on Windows, works on Mac and so forth. The suggestion that I would have for that audience member is to put in place a set of policies or maybe review the set of policies that you have for what you do with the traffic from personal applications, and make sure that that traffic is not going to corporate networks.
Once you ensure that, then ensure that you've got the right level of security on the corporate traffic that you do want to control and manage. In general, what we recommend to people is Per‑App VPN for connection to On‑premise services.
If you're connecting to cloud services, then you may not need that though. You may not want to help in your traffic even though you may want to secure your authentication traffic.
Mandy: How long will it take my company to go through the GDPR process?
Ojas: It will vary by company. What it will most vary or most depend on is the level of structure that you have in place or the security program that you've implemented.
What I would recommend to any organization is to go through the seven‑step process we talked about here, or whatever your version of that might end up being. Spend a few days and really do a assessment, the mobile deployment that you have to get a sense of what the gap is.
If you've actually gone through a structured security program, as you've done your mobile deployment, getting to GDPR compliance will primarily be consist of two things. One is making sure there aren't unmanaged devices or apps out there. If there are, quickly bring them under management, which does not take long as soon as you identify them.
Secondly, really identify what services are delivering data to those devices, so you can keep the unauthorized devices out. I believe that if you have a structured program in place, you'll have an assessment period of a week or two to go through and really assess what your GDPR gaps might be.
Depending upon the gaps, it could be a matter of weeks, could be a matter of months, but I think for most structured programs, is probably a matter of weeks to get yourself to compliance.
If you're just at the beginning of thinking about mobile security, then you probably have a little bit of a longer road ahead of you, but I would still say that that road is a matter of months and not potentially the tens of months that some of the other elements of the IT organization will encounter as they think about GDPR compliance across the broad scale data warehouses that people have.
The moral of the story, I guess, is that the mobile elements of GDPR are straightforward to put in place. They just need to have awareness within the organization and then the appropriate resourcing and the appropriate time to make sure that they happen before May.
Mandy: That concludes our Q&A session. Thank you, Ojas. Thank you everyone for joining us for today's presentation. Just as a reminder, I will be sending out a recording of the webinar along with the white paper that was just mentioned. It provides a starting point for deploying in and as part of the GDPR compliance security program.
I do appreciate your participation and attention on the webinar today. Have a great rest of your day. Thank you so much.